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A Sillily of complex systems with shared family software arehitecture. 



09.03.2000 



The invention relates to a ftmily of complex systems vnUx a shared 

architecture. 



5 Such a family of complex systems is known &om the article 'Creating 

architectures with building blocks ' by F.J. van deer Linden and J.K. Miller in IEEE Software 
12(1995)51-60. 



10 The known &mily of complex systems is in &ct a family of 

telecommunications switching systems. The family members have a common software 
architecture. The common software architecture enables software development and testing to 
be shared among family members. 



15 

An object of the invention is to provide a family of complex systems in which 
a relative large degree of diversity among present and/or future family members is siqsported 
by the common software architecture. 



20 

This object is achieved according to the invention by a &mily of comply 
systems vsiierein 

- a component framework supports participating plug-in components 
individual plug-in components provides one or more services and 
25 *- the component framework defines roles providing one or more common inter&ces for 
services of several plug-in con^>onents. 

The roles provide for common interfiaces between the services of the plug-ins 
and clients which use the services offered by the plug-ins. The invention notably achieves 
advantages for systems that have some degree of complexity such that a software architecture 
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platform is usually raaployed in order to drive and comrol the complex system. The 
advantages of a family of complex systems according to the invention are more marked as 
the systems are more complex, but the invention may also be advantageously employed in 
the software architecture of relatively simple systems. 
5 Usually, the clients are fomied by functionalities of the complex system, 

which indirectly serve commands supplied by the user of the complex system. The clients 
may also be direct actual users. Clients use tiie services from the plug-iixs by accessing the 
component framework. The component framework according to the invention is itself active 
in setting up roles, i,e- common interfeces for services of several plug-ins. This achieves diat 
10 the client is not involved in de structures of the componmt framework. Notably this is 
achieved because the functionalities offered by plug-ins are modelled as services and 
common functional concepts of the plug-ins are combined at their own roles. According to 
the invention the component framework provides a central access without revealing specific 
configurations to the client. Thus, diversity e.g. in future generations of the femily is widely 
15 supported. In this respect it is to be noted that the fisunily of complex systems may share the 
component framework. Various different members of tiie femily are formed by coupling 
different plug-ins to the shared component framework- A next plug-in may be ixiserted 
without diflBculty as its services may be interfaced to the client via the aheady existing roles. 
This makes it easier to create a new femily member ^^ch has^ witfi respect to the existing 
20 family, one or more new plug-ins with their services. According to the invention the services 
of the new plug-in are interfiiced to the client via roles that are shared with service of earlier 
plug-ins. Alternatively^ fhc component framework allows easy set-up of new roles for the 
service of the new plug-ins without substantial redesign of the component framework. 
Preferably when setting-up roles the expected diversity of new plug-ins is carefully analysed 
25 so that tiie setting-up of new roles remains limited. 

In a particular example^ the present femily member is an diagnostic imaging 
system of which the components such as the x-ray source, the x-^y detector, the stand 
carrying the x-ray source and the x-ray detector and the patient table are moveable. The 
respective components give rise to software plug-ins which cotxtxol the respective services 
30 relating to individual movements of -fliese components. These plug-ins are all interfaced to 
the component framewotk by way of one role relating to movements. In a next generation for 
example an ultrasound imaging modality is incorporated in the medical diagnostic system. In 
this next generation diagnostic imaging system an additional movement, namely movements 
of an ultrasound transduce are involved. The software plug-in for supporting and controlling 




3 09.03.2000 
the movements of the ultrasoimd transducer are easily interfaced to the already existing xol . 
The component firamework then is immediately abl to detect and initialise services involving 
the additional movement of the ultrasound transducer. 

Within a generation of complex systems, notably medical diagnostic sjrstems, 
5 respective family members include high-end and low-end version of a common functionality* 
For exan^le respective x-ray examination apparatus may have either a high-end patient table 
which allows many complication movements or a low-end patient table ^^tdch only b11o\^ a 
&w simple movements. The software plug-ins relating to either high-end or low-end versions 
ate interfiaced to the same role. Hence, according to die mvention, the software architecture 

10 having the component framework stq>ports the entire range fit>m high-end to low-end of the 
common functionality. 

These and other aspects of the invention are further elaborated with reference 
to the in^eferred embodiments as defined in the depeisdent Claims. 

According to the invention one or several component frameworks may be 

1 S employed in a complex system. Notably, separate component frameworks may be employed 
for respective aspects of use and control of the complex system at issue, particular examples 
are an application component framework which deals with the application domain, such as 
procedures for acqniring unages in a medical diagnostic system. There may also be a 
technical conq>onent framework which deals with control of the hardware, such as the 

20 geometry functionalities of an x-ray examination apparatus. Further, an infrastructure 

component framework which is related to computing platforms of tiie complex system. The 
infrastructure component framework is usefbl for dealing with field-service related functions, 
such as calibrations and settings. 

Preferably, the individual complex systems, being a member of the &mily as 

25 defined in Claim 1, include an inventory function in the com p onent framework. The 
inventory function assesses the actually available services firom the plug-ins for this 
individual complex system. Thus, the inventory ftwction provides an availability interfiice 
dirough which clients can detemiine which functionalities can be realised. This further 
achieves that the component framework acts as a central access point for the functionalities 

30 siq)ported by the available services. The assessment of available services may be performed 
v^en the complex system is started-up, but regular updates of the assessment may also be 
performed eithw during operation of the complex system or when a new plug-in is added to 
the complex system. 
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Preferably, the component framework is active in that the available services 
ate coirectly initialised when the complex system is switched-on or tegular updates are 
perfonned. In this way the correct initialisalion of the complex system is done consistently 
for most or even all features the complex system. As to regular updates fbe conq>onent 
5 framework provides an infrastructure for the plug-ins. When a new plug-in is added, only the 
component framewoik needs to perform an update of the available services. 

An easy way to assess the available services from tije plug.ins coaled to the 
componrat framework is to m a int ai n a list of the services witti thrar properties and 
requirements. Such a list is preferably in digital electronic form. Preferably, the con^nent 
10 framewoik generates, updates and store this list of available services. Advantageously, the 
list of services is provided in the form of a distributed set in which to services of one or more 
plug-ins are assigned identifiers depending on the behaviour of the services; thus, services 
having the same behaviour are assigned to the same identifier and services having different 
behaviour are assigned to different identifiers. The distributed set further accounts for at 
1 5 vMcb. plug-ins which services aie available. Because the distributed set resides in the 

component finmework, the location of the service is of no concern to the client using such 
service. 

These and other aspects of the Invention are facfher elaborated by way of 
example with reference to the detailed embodimoits discussed heidnafter and with reference 
20 to the accompanying drawing 'vs4ierein 

The Figure shows a diagrammatic representation of a 'Service Component 
Framework*, actively connecting Plug-ins and Clients. 



25 The compon«it framework according to the invention is a software component 

itself, yMch is mdicated as a service component framework (SCF), and defines one or more 
roles ^Us) to wluch one or more oompononts (Pig a,Plg b,Plg o) can be plugged-in. These 
plug-ins provide some kind of service (Svo al - Svo c2) via their interfece, \Mch can range 
from a software representation of a scarce hardware resource, e.g. image processing nodes 

30 M^ch provide services like noise reduction or image subtraction, to some piece of logical 
functionality, e.g. a spelling checker. This means that a plug-in is a container of one or more 
services. Next to the plug-ins, there are usually clients that use the functionality provided by 
the component fismewoik and plug-ins as a whole. The component framewoik is active in 
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connectixig interfaces of plug-ins and providing via the respective roles» the ftmctionality of 
these inter&ces to other clients. 

For exanQ>Ie, for the geometry sub-domain of a family of X-ray diagnostic 
systems such a service component firamewoxk has been developed The geometry sub- 
5 domain e.g. involves the functionalities of &e possible movements* rotations displacements 
of componrats of the X-ray system, such as the movements of the X-^ray source and X-ray 
detector, patient table and the stand \^ch carriers the X-^ray source and X-ray detector In the 
family architecture, geometry has been identified as a unit This unit as a i^^le provides, 
amongst others, a number of movements to position the patient, like TableHeight and 

10 TilfTable. Various geometry hardware modules exist, each, providing a subset of all possible 
movements (e.g. about 100 movements in total). To deal with this diversity the hardware 
model is mirrored into software by one framework component, i^ch provides the genraic 
functionality, and a niunber of plug-ins, each providing a number of movements to the 
framework component la this example, the movements are thus modelled as the services that 

IS axe provided by the plug-ins. The various clients of this component framework can use these 
movements without worrying about the internal component framework stmcture. This kind of 
framework has also been applied for other sub-domains of the product family, e.g. in 
acquisition for adding acquisition procedures, in reviewing for adding analytical functions, 
and in the field-service domain for field-service functions (calibratian3 configuration, etc.), 

20 The main advantage provided according to the invention of the service 

component framework is related to the degree in i^ch the functionality of the sub-domain 
that is involved can be standardised and modelled as services, and the support for diversity 
that is needed. In case of the geometry example the movements are identified as the main 
concepts, and these can be handled as services provided by pli^-ins that match the hardware 

25 modules. 

Two important issues concerning the service component frameworks are tiie 
responsibilities that the framework component has, and the abstractions and interfaces that 
the plug-ins must provide. These two issues are discussed hereinafter. 




3 0 When defining a service component fitonework, a nvonber of responsibilities 

are advantageously taken into account for the firamework component, viz.: 
♦ Provide a support for diversity 

An important responsibility of the framework component is to support diversity. This 
means that the framework component airports easy pluggability . For this, it is important 
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that the (expected) forms of diversity are carefully analysed and the right concepts axe 
selected, in the geometry example the movement concept This is closely related to the 
interface issues, discussed later on. 

♦ Provide a central access point 

5 Since it enables diversity and because this diversity preferably does not pixipagate 

through the entire systan, a framework component serves as a central access poiat for 
the functionality provided by the plug-ins without revealing the specific configuration of 
the plug-ins to the clients of this functionality. An important activity here is tnglnt^imng 
a list of all available services, i^ch are actually located in the plug-ins. In the geometry 
1 0 example, the movem^ts are identified via a character string, describhig the kind of 

movement, e.g. TableHeight, TiltTable, etc. 

♦ Provide a basic infrastructure 

Individual plug-ins preferably do not dirocfly interact witii parte of the system that may 
vary over time. Instead, the framework component provides some land of infrastructure 
15 to the plug-ins. This way, when the environment changes, only the framework 

component needs to be i^dated. Such an infrastructure is for example responsible for 
correctly initializing all plug-ins and their services. 

♦ Provide functionality 

Next to the basic responsibilities mentioned above (connection management and 
20 infrastructure), the framework componait may also contain additional functionality, 

since it is a component of its own. This is for example the case for the geometry tmit 
where the framework component is responsible for adding resource management and 
scheduling in order to deal with the scare movements in a controlled way. Another 
possibility is that the framework component already contains some services and can 
25 operate on its own, so that adding plug-ins to that framework is not mandatory. 



The main responsibility of the plug-ins is to provide "die functioi^ity 
(services) to the framework component This may occur at initialisadon-^time of the system or 
durfaxg run-time when the service is actually needed. The architectural concepts, interfeces, 
30 and infrastructure to vAAch the plug-ins must adhere to are defined by the component 
framework. 



Since component frameworks are introduced to deal vnth diversity, they 
advantageously are able to deal with various plug-ins providing their own specific 
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functionality. This ftinctionality is handled by tiie component firamewoxk in a generic vray 
and provided to interested clients. This means that the xig^t abstractions must be chosen both 
for the interface between the plug-ins and the component framework and between the 
component framework and its clients. 
5 The roles acting as interfaces, are on the one hand clear and straightforward to 

use, and on the other hand that they are stable. 

For liie movements in the geometry example^ several inter&ces are choseUj 
each representing one group of movements, making the interface more specific and easier to 
use. In this case, ^ semantics are stable (a movement is a known concept in the domain), 
10 but the syntax may slightly change in the future. 

When defining a unit or a component in the Systran, a deliverable is provided 
to sujiport the clients using liiis unit or component This deliverable is called the teqiiirements 
specification. A requirements specification specifies the interface that is provided to &e 
1 5 clients. It contains, amongst others, the following parts: 

♦ class diagrams 

These diagrams contain the inter&ce classes that the unit^component provides to its 
clients. The classes in a class diagram are related to each other via associations, 
aggregations, and generalisations. Each diagram has an annotation, describing the group 
20 of classes as a whole. 

♦ sequence diagrams 

A sequence diagram represents an interaction, which is a set of messages exchanged 
among objects within a collaboration to effect a desired operation or result In this 
context, the sequence deals with the interaction between the unit/component and its 
2S users, A sequence diagram contains a possible sequence of events, and is thus not 

complete in that sense. 

♦ class desoiptions 

For each class, a description is made. This description is based on the model laid down 
by the class diagrams. For each class, the attributes, operational and state diagram can be 
30 specified. 

♦ software aspects 

Special attention is paid to the various software aspects as identified by the architect that 
cut across most software components, like initialization, error handling, graceful 



Printed: 17-11 -20^0 



09-p3-2C)00| >122EP>P 

8 09.03.200a 
degradation5 etc. These aspects are related to tiie quality attributes. For each relevant 
aspect a separate section is idratified. 

Theinter&ce of a imit/corr^ponent is described based on a XJML model with 
S classes and associations . When dealing with component frameworks, some additional issues 
pre&rably are taken into aocoimt. For exanqslo ^ geometry xmit consists of a service 
component framework with a number of plug-ins. In this case, the functionBlity provided by 
tlie geometry unit as a whole in a specific £eunily member cannot be given by one document 
Instead, two document ^es are used, viz.: 
10 > ♦ generic requirements specification 

This requirements specification describes flie generic interfaces fliat are provided to the 
clients. All service concepts, in this case 'ttie various types of movements, their attributes, 
etc. are described in this document However, no specific services (instances) are 
described. 

15 ♦ specific requirements specification 

Individual plug-ins provide their own specific requirements specification. This 
requirements specification describes which services are provided and which specific 
properties the plug-in lias. For each movement, amongst others, the MaximumPosition 
and MaximumSpeed need to be specified. The generic requirements specification 
20 focuses on the generic meaning of the service interfaces, i^eteas the specific 

requirements specifications deal with service specific issues. 

Next to the phiggability of the actual software component plug-ins, it is also 
important to have this pluggabilrty on document level, as described above. This makes it 
easier to detOTnine the complete requirements specification for a specific &mily member, 
25 since each plug-in has a related document describing flie specific services of that plug-in. 

This agrees with the idea that a component is the imit of packaging, i.e. a component consists 
not only of executable code, but also of its interface specifications, its test specifications, etc. 

A component framework defines the boundary conditions to which each plug- 
in must adhere. Since usually several plug-ins are developed for a framework, it is 
30 worthwhile to provide support for plug-in development, This is achieved in that a 

docimientation template is provided for the specific requirements specifications. This way, 
the auth r knows what needs to be specified, and all relevant issues are addressed. 

The interfaces and design of a component framework dictates the design of the 
plug-ins. That is why also sixpport can be given for the design documentatioii of plug-ins. 
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The interfiice files of the interfiaces that the plug<^in needs to support must be 
provided. Furthermore, some classes that are relevant for each plug-in can be provided. It is 
also possibl to provide a complete example plug-in, containing aU relevant information to an 
implemienter of a plug-in. 
5 Purser, a test specification is preferably provided against which each plug-in 

can be tested. It is even possible to provide some test harness in v^ch these tests can be 
performed automatically. 




As stated before, fhe product family architecture does not show diversity on 
10 &e level of units. This means iliat the units form a stable skeleton of the system . The 

diversity can be found inside the tmits . One of the means to deal with this is to divide tiie unit 
model into a generic part (related to one or more component firameworks) and a specific part 
(the plug-ins). Each unit has a part of the overall domain model assigned to it as a startix^ 
point for the design activities. A nuniber of steps in this iterative modelling process can be 
1 S identified (using the geometry example): 

1 . The design activity adds design classes to the assigned domain model, e.g. a manager class 
maintaining a list of all movemrats is introduced, and a priority based scheduler class is 
added for handling the scarce movement resources. 

2« Then the commonality and diversity is analysed. This is closely related to the diversity, in 
20 features and realisation techniques tixat the product family must si^port Identify which part 
of the model remains stable^ and which part will vary between the family members and in 
time. The larger fiie selected generic part, the less the resulting flexibility is. 
3. Based on the previous analysis, it must be identified which concepts must be used for the 
services ^lat the plug-ins should provide to the component framework. For the example, the 
25 movements are selected as the services. It may be the case that by introducing generic 
concepts, Hie variation can be handled better (these concepts may even be useful in the 
domain model). For exaxx^Ie, various specific parts of a geometry have specific position 
information. By introducing a concept like a GeomebyComponent class containing position 
information, tiais information can be handled in a generic way. 
30 4, Identify ^^ch additional design concepts are needed by splitting the model up into two 
parts, i.e. the framework compon^ and the plug-ins. This splitting up has more 
consequences for component frameworks than for example for class frameworks, where 
techniques like inheritance are also allowed. For example, the generic part gets the 
responsibility to start-up the plug-ins during initialisation f the system. 



Priht(4d:^7-11-20G0 



10 



09.03.2000. 



Summarising, step 1 contains the 'normal* design activity, la. step 2, tiie 
diversity is analj^ed. The relevant service concepts that must be provided by the plug-ins are 
identified in step 3. Finally, step 4 introduces the infiastroeture in yMdh these services are 
5 handled. 

In developing a service component fiamework, many factors play a role that 
may lead to modificatioixs of intex&ce, e.g. changes in the domain model, the right concepts 
are not chosen, etc. So, normally a couple of iteradona are needed. 
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CLAIMS: 



1. A family of complex systems having a shared &mily architecture and wheiein 

- a componont framework supports participating plug-in components 

- individual plug-in components provides one or more services and 

- the component framework defines roles providing one or more coixunon interfaces for 
S services of several plug'-in components. 

2. A complex system bei^g amember of the family as claimed in Claim 1, 
lA^iereui the component framework includes an inventory function for assessing available 
services in the participating plug-in components. 

10 

3. A complex system as claimed in Claim 2, wherein the inventory fimction is 
arranged for initializing tiie services. 

4. A complex system as Claimed in Claim 2 wherein the Inventory function is 
1 5 arranged to asses available services at initialization of the system or during run-time of the 

system- 
s' A complex ss^stem as claimed in Claim 2 ^^erein the inventory function is 
arranged to maintain a list of the available services. 

20 

6. A fiamily of complex systems as claimed in Claim 1, wherein the family 

members are medical diagnostic systems, in particular x-ray examination apparatus. 

7: A complex system^ in particular an x-ray examination apparatus having 

25 software architecture and wherein 

- a component framework supports participating plug-in components 

- individual plug-in components provides one or more services and 

- the conqionent framework defines roles provides ne or more common inter£atces tot 
services of several plug-in components. 
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ABSTRACT: 



A £ainily of complex systems has a shared family architecture. A component 
fiamework siqpports participating plug-in components. Individual plug*-in components 
provides one or more services. The component firamewoxk defines roles providing one or 
more common inter&ces for services of several plug-in components. Notably» the component 
S framework includes an inventory function for assessing available services in the participating 
plug^in oon^^KmeEnls. 
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